【レポート】AKIBA.swift 1周年 スーパーコラボ勉強会【アーキテクチャ、開発便利ツール、RxSwift などなど!】 #super_swift

【レポート】AKIBA.swift 1周年 スーパーコラボ勉強会【アーキテクチャ、開発便利ツール、RxSwift などなど!】 #super_swift

Clock Icon2017.04.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AKIBA.swift 1周年!

2017年4月17日、弊社の田中賢治田中孝明が主催する AKIBA.swift の1周年記念勉強会を開催しました。

【ありがとう一周年!】AKIBA.swift 1周年 スーパーコラボ勉強会 2017/4/17 #super_swift

クラスメソッド株式会社が主催する、プログラミング言語 Swift とその周辺技術の勉強会です。

発展を続ける Swift とその周辺技術の動向を追い、初心者/上級者/老若男女を問わず、情報交換の場として機能することを目的としています。

趣味/仕事で Swift に触れている方 Swiftを用いたiOS開発に携わっている方 これから Swift の勉強をはじめるという方 なんかSwiftが好きだという方 などなどスーパー歓迎です!

Swift を使ったアプリ開発をしている上で非常に有用な情報が盛り沢山でした。本ブログは、その発表内容のレポートをお送りします!

バージョンアップの対応を軽減するためのサービス(マスティフ)の構築

iOS Test Night 平田 敏之(@tarappo) さん

DeNA の SWET (Software Engineer in Test) といわれる、品質向上・生産性向上をミッションとするテスト基盤チームに所属されています。バージョンアップ、そしてマスティフについてについて発表いただきました。

  • バージョンアップで苦労してますよね?
    • 新バージョンのコスト見積もりが難しいので先延ばし…
    • バージョン固定なのに動かない
    • いつバージョンが上がったのかが分からない、読めない
  • やりたいこと
    • 第一次判断を早くしたい
    • 既存ライブラリが動くことを定期的に動作確認したい
  • マスティフ
    • Gemfile、CocoaPods、Carthago、Xcodeのバージョンアップを監視
    • バージョンアップを digdag で行う
    • バージョンアップを発見したら Jenkins が CI して動作確認できる
    • Xcode のバージョンアップも通知する
    • 結果管理は作成中 (ビルド時間など、バージョンアップの判断材料を提供予定)
    • fastlane を活用している
      • Fastfile は別の Fastfile を読める
      • Override もできる
      • ので、マスティフの Lane の取り込みがしやすい
      • 少ない工数で導入可能
  • マスティフを活用した動作確認フロー
    • ライブラリのバージョンアップを発見したら
      • 最新のバージョンで動作確認
      • 動いたらバージョンアップ
      • 動かなかったら1つ前のバージョンで動作確認 (原因特定を目指す)
  • Xcode について
    • クラウドだといつ Xcode の最新バージョンに対応するか分からないので Jenkins を利用
    • Application Director Plugin
      • 複数の Xcode バージョンの扱いを簡単にする Jenkins プラグイン
      • Jenkins の最新仕様に対応中、引き続き使えるように鋭意開発中
      • インストールされている Xcode のバージョンに基づいて Label を付与する
      • Xcode でなくても使える
  • マスティフのレポート
    • fastlane のレポートとして出力 (report.xml)
    • Slack に通知される
  • 最後に
    • 苦労を軽減するものを提供している
    • 疎結合として作っているので、みんなが使えるものとして随時公開していく予定
    • 是非是非触ってください
    • 端末の OS バージョンへの対応も計画中
    • Android も対応しているので、モバイルアプリ開発全般に使える

iOS Test Night の第4回目が5月24日(日)にあるので、興味がある方はぜひご参加を!

DangerでPull Request レビューの指摘事項を減らす

iOS Test Night 前田 隼輔(@duck8823) さん

平田さんと同じく DeNA の SWET グループに所属されています。本日が初登壇!CI、CDの環境整備、ツールの検証、マスティフの開発に携われています。

  • PR でこんなことありませんか?
    • ビルドしたの?
    • 対応したチケットは?
    • master にはマージしないで
    • ロジック以外の指摘事項が多い
  • Danger とは
    • PR の確認事項を自動化できるツール
    • Dangerfile を作成
    • チェック結果は GitHub などのホスティングサービスのステータスに反映できる
    • 情報も取得してくれている
    • つまり、PR の確認を自動化する基盤の提供
  • Danger でできること
    • Dangerfile は Ruby の構文が使える
    • git や github といった変数が使えて、ここに色々な情報が含まれている
    • Ruby と GitHub API の知識があればなんでもできる!
    • しかし、目的は見失わないように…
  • SWET での事例
    • 利用しているツールは GHE、Jenkins (+ GitHub PR Builder Plugin)、fastlane
      • GitHub PR Builder Plugin : PR にコメントを書くとビルドを走らせることができるプラグイン
      • fastlane : lane 別に色々な処理に振り分けられる
    • fastlane actions danger でできることが見れる
      • use_bundle_execfalse にしないと使えないことがあったので留意する
  • チームでやっている PR ルール
    • Storyboard や Xib の変更はスクショを貼ること
    • ディレクトリに変更があったらテストを実行すること
    • ビルドやテストが実行されていた場合、最新の結果が成功していること
    • これらを Danger 化することでチェックを自動化している
  • 共通なものはプラグイン化する
    • PULL_REQUEST_TEMPLATE.md があり、テンプレートから変更されていること
    • TODO のチェックは埋まっていること
    • プラグインの作成も簡単
    • Gemfile に追加するだけ
    • これらを共通的にできるようにしている
  • ラベル
    • Danger でチェック済みであることをラベル化している
    • ラベルがあると安心してレビューできる
  • 最後に
    • 最低限の条件のチェックを自動化できるので、指摘事項を減らしましょう

Danger は非常に便利で有用ですね。弊社でも使ってみたいと思います。

Swift coding Strategy

AKIBA.swift 田中 孝明(@kongmingtrap)

クラスメソッド株式会社でモバイルアプリのバックエンドを担当している、Swift や Scala や JavaScript を使った業務をしている田中の発表です。

  • 仕事で出張をたくさんしている
    • 沖縄、大阪、
    • WWDC 2017 もいける
  • Strategy
    • Strategy パターンを想像する
    • 今日はプログラミングではなく、Strategy of AKIBA.swift
    • 戦略
      • 目標を達成するために色々うまく考えること
      • バッドノウハウなど、クラスメソッドだけで共有できない情報を共有できるようにしたい
      • 有名人と仲良くなって困った時に聞けるようにしたい
      • スタープレイヤー化してコンテンツ化したい
  • AKIBA.swift 1周年
    • 各月開催
    • 開催ブログを書き、スピーカーに敬意をはらう
    • ゲストスピーカーを招く
    • 場所を提供する
    • 毎回テーマを決めてやる
  • 実際は
    • うまくいった時はあるが、「フリートーク会」があった
      • 登壇者任せ
    • コラボの話が出てきた
      • 実は、秋葉原で開催はあまりしてない
    • 勉強会という名の忘年会もやった
  • それ必勝の術、合変の形は機にあり。
  • Recap
    • 戦略より戦術
    • 優秀な後方支援によって支えられました
    • 鮮度が下がらないように、次の日までに書く
  • One more thing...
    • 秋葉原から大阪へ出張勉強会も
    • BUKURO.swift さんとの合同勉強会も

1周年らしい良いまとめでした。2年目も引き続きよろしくお願いします!

iOSクリーンアーキテクチャのデータ戦略

AKIBA.swift 田中 賢治(@ktanaka117)

iOS エンジニアとして iPhone アプリ開発に従事している田中です。最近では try!Swift のハッカソンで Firebase 賞を受賞。素晴らしい!Apple Dev Center で WWDC 2017 のチケットが見れるそう。ニコニコドヤドヤしていました。

  • 注釈
    • モデルビュープレゼンターは MVP、クリーンアーキテクチャは CA
  • MVP について
    • Presenter の役割は、VC に対して描画の指示を行うこと
    • Model から Presenter に返却するデータはどんな形が適切か?
    • 例えば JSON は?
      • これは NO!
      • Presenter が Model から View に対して必要なデータに書き換えるという責務が増える
      • 本来の役割を見失ってしまう
      • なぜ役割を見失うのか?
        • Model が原因
        • Model は実装者に委ねられる部分が多い
          • Service とか Manager とか Util とか…
  • Clean Architecture は?
    • Model の曖昧さを細分化して、より明確化している
    • Usecase、Translator、Model、Repository などなど
      • これらも Domain Layer と Data Layer に分かれている
    • Presenter が Usecase に投げて、Repository に問い合わせて、Translator を通して Data Model に変換する
      • Presenter は描画に集中できる
    • MVP の場合も、データ変換の役割は別にした方が良い
      • Clean Architecture から得られる知識も多いので活用しよう
  • まとめ
    • MVP や小さなフレームワークを使っていて、曖昧な部分は Clean Architecture から学んでみよう
    • Clean Architecture はフルアーマー。一つ一つをよく知って、武器として活用しよう
    • 曖昧さは逆に言えば決めの問題。人に伝わりやすく、納得できる責務分けが大事。

アーキテクチャは一択ではなく良いところどりをしましょうという話でした。何より学ぶことが大事ですね。ベストなアーキテクチャを考えられるように引き出しを増やしていきたいものですね。

来年のtry! Swiftを10倍楽しむために

Swift愛好会 七島 偉之 (@jollyjoester)

Repro で iOS エンジニアとして従事されている Wantedly にて全て熟知称号・自称他称カンパイヤーの七島さんによる発表です。

  • Strategy of Swift 愛好会
    • Swift 好きが集まってワイワイ
    • レベル、経験など不問
    • 月1開催 (平日談義、休日耐久)
    • 発表時間に制限なし
    • 気楽に聞いてもらえれば良い勉強会
    • ぜひ参加を。次回は4月28日。
  • try!Swift
    • 3月2日〜3月4日に開催
    • 参加者は、本勉強会参加者のうち半数!
    • 2018年も開催予定!
    • 七島さんはオーガナイザーになる!(予定)
  • オススメの楽しみ方 : 登壇する
    • LT もあるけど、ちょっと辛い、ハードルが高い…
  • オススメの楽しみ方 : すごい人と話す
    • 世界的にすごい人(スピーカー)が来るので、直で話す
    • 捕まえて、直接話して質問したり議論したりする
    • 英語は必要、Swift の知識も必要
    • 何より大事なのは、話題!(日本でも、これがないと辛い)
  • 2018年に向けて…
    • 話したい人の Twitter をフォロー
    • 過去の try!Swift のネタをチェックしておく
      • まとめがあるので見る
      • Tokyo だけじゃもったいない
        • ニューヨークやバンガロールのネタもチェックしたり
        • Realm のニュースに動画や書き起こしなどが配信されているのでチェックする
  • せっかくなので例を
    • Swift and the Lagacy of Functional Programming
      • Realm のページで動画、スライド、書き起こしが見れる
      • スライドが動画の時間に合わせて変わるゴージャス仕様
      • 字幕もあるし書き起こしもあるので、英語の発表を聞き慣れていない人でも勉強しやすい形になっている
      • 英語も聞きやすいのでオススメ
        • Swift で型で分解と再構成を行う発表
    • Result Oriented Development
      • 日本語で翻訳済み!
      • 日本語、英語で見ると非常に勉強になる
  • まとめ
    • try!Swift の振り返りで、Swift も英語もパワーアップ!
    • 共通の話題を踏まえれば、スピーカーの人と話ができる!?

try!Swift を知っている七島さんだからこその、信頼できる楽しみ方ですね。

Carthage を使った非オープンな社内開発

Swift愛好会 星野 恵瑠 (@lovee)

MAGES で業務をされている、 lovee さんによる発表です。

  • この世の果てで恋を唄う少女YU-NO 2048 というアプリを最近リリース
    • Carthage でライブラリ管理
  • Carthage のイメージ
    • CocoaPods の代用品?
  • Carthage はそれだけではない
    • github xxx -> 3.0 など
    • git https://xxx -> 'develop' などもできる
      • 社内 OSS にも使いやすい!
  • 対応の方法
    • プロジェクト作り、Scheme で Shared にチェック
    • carthage update を実行
    • Framework をリンク
    • Search Path を設定
    • Run Script を追加
    • Swift 内で import して使う
  • Carthage のメリット
    • コードの再利用
    • ビルド時間短縮
    • 同じ Framework を複数のプロジェクトで開ける
    • 設計について考えさせてくれる
      • 汎用性のために機能を細かく分割
      • API のアクセス管理などの設計ができる
      • 開発スキルアップ!
  • Carthage のデメリット
    • ブレーカーが使えなくなる
    • コーディングから実機テストまで時間がかかる
    • コンパイラフラグが使えなくなる
  • デメリットの解決
    • まずはライブラリ化せずにプロジェクト配下で作る
  • One more thing
    • 他の発表 (Playground の活用方法) もしたので、ぜひ参考に。

「まずはライブラリ化せずにプロジェクト配下で作る」は非常に大事なポイントだと思います。必要なものを作り、それができたら汎用化という流れが一番効率的だと思います。

休憩がてらiMessageでもいかがでしょう

Swift愛好会 Gotou Reiko (@burakon)

Arrvis で業務をされている、Swift の愛好会の LINE スタンプを作った!というエイプリルフールネタを作成された、非常にユニークな Gotou Reiko さんによる発表です。

  • iMessage のステッカー
    • 思い浮かぶのは LIN◯E さんのスタンプ
    • iMessage に、ステッカーがない、ステッカーが使われていない
      • LINE さんの方が多いので、iMessage はどうなの?
  • iMessage のステッカーを使ってみると…
    • ロングタップでメッセージにくっつけられる (びっくり)
    • アプリにステッカーが組み込まれる
      • Message App Extension を使っていると、アプリをインストールするだけでステッカーもインストールされる
  • Message App Extension を使ってみる
    • MSMessengerViewController という View Controller でアプリを作れる
    • いわば、ステッカーの場所でアプリを起動し、動作させることができる
  • Sticker つくろう
    • 作り方は公式に載っている
    • アイコン、スタンプ作るのがだるい
    • テンプレを公開した

Layered ArchitectureにおけるRxSwiftを用いたError伝搬

Kyobashi.swift 井原 岳志 (@nonchalant0303)

リクルート・マーケティング・パートナーズで iOS エンジニアをされている井原さんによる RxSwift のお話です。

  • Layerd Architecture とは?
    • インフラ / ドメイン / プレゼンテーションで提供する
  • エラーはどのレイヤーにもあるよね
    • インフラだったら、認証エラーやコネクションとか
    • ドメインはロジック、変換エラーとか
    • プレゼンテーションでは、アラートを出したりリトライを促したり
      • 認証エラーとかは詰み
  • RxSwift を使うと?
    • subscribe - onError
    • ストリームでガンガン繋ぐのでエラーの発生箇所が分かりづらい
    • 各レイヤーのエラーを定義してあげる
  • Layerd Architecture では
    • Presentation では Event、インフラ、ドメインでは Observable
    • Observable.error と Observable.catchError を使う
    • Swift の error として返されるので、型をつけてあげる
    • ドメイン層では throw する
      • Traslator でエラーの型に変換する
    • プレゼンテーションでは
      • 特定のエラーの時に特別なエラーを返す
        • 特定の処理を行わせたい場合に判別できるようにする
      • 大事なのは、依存させないこと
  • まとめ
    • 設計に正解はないので、一案として参考に
    • catchError では返さずに回復させることもできるので、様々なユースケースに対応

Rx のエラー処理について、Presenter が提供する実際のエラーの出し方まで意識された素晴らしい設計でした。

RxSwift 3.3.0: Observableのフレンズが増えました

Kyobashi.swift 保坂 智之 (@tondol)

保育園と保護者をつなぐサービス「kidsly」 のアプリを開発されている、リクルート・マーケティング・パートナーズの保坂さんによる発表です。

  • RxSwift とは?
    • try!Swift にもトークがありました
    • イベントを Observable で表現
    • フローを定義すると UI が自動で切り替わるような世界
  • よくあるバリデーション
    • 例えば…
      • メールアドレスとパスワードが必要など
    • リアルタイムにエラーを表示するのが RxSwift は非常に得意
  • よくある API 呼び出し
    • 普通に実装してみたら、あれ、2回目以降動かない
      • bind だと onNext() が終わったらすぐに onCompleted() になる
      • subscribe だと onNext() を購読し続けられる
  • 新しいフレンズたち
    • Single、Maybe、Completable
    • Rx ファミリーではお馴染みの、Observable のフレンズ
    • Single : より強い制約、Promise に近い役割を持たせられる
      • Observable.asSingle で作れる
    • Completable : Single<Void> のようなもの
    • Maybe : 値が0個でも表現できる
  • まとめ -すぐ complete する Observable は Single で表現しよう!

まとめ

UI に近い取っ付きやすい話もありつつも、Clean Architecture や Layerd Architecture などといった設計の実践的な話まで、Swift に関する様々な最新技術が幅広く学べる勉強会でした。AKIBA.swift は2年目も細く長くやっていきます。今後も引き続きよろしくお願いします!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.